FEEDBACK
EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
EarthWeb Events
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
Perl Journal
RoadCoders
SysOpt.com
Y2K Info
|
|
Chapter 2
System Security
- • Removing The Last Logged On Username
- • Displaying A Logon Message
- • Allowing Automatic Logons
- • Setting Permissions On Registry Keys
- • Setting Auditing On Registry Keys
- • Changing The Logon Screen
- • Locking And Unlocking Windows NT
- • Configuring A Screen Saver To Automatically Lock
Administrator’s Notes...
Components of the Windows NT security system are encountered in virtually all chapters of this book. This is because the Windows NT security system is a fundamental and underlying component of the operating system. The points covered in this chapter are pure security issues, along with the technology used to implement the security system. (For a more complete picture of Windows NT security, these points should be combined with the account information in Chapter 5 and the NTFS permissions discussion in Chapter 4.) In addition, Chapter 8 provides details on examining the security audit log.
A key point regarding Windows NT security is that the security system can only protect data when the operating system is in use. In other words, physical security needs to be considered. If the Windows NT system can be restarted using a different operating system, the data held on Windows NT volumes can be accessed. Like all other operating systems, Windows NT does not encrypt the data held on disk.
The Logon Process
The following steps describe the components used in the validation of an interactive logon for a user. Key components are then covered in more detail.
- 1. Pressing Ctrl+Alt+Del invokes the Windows NT Logon Information dialog box.
- 2. The user enters the user account details, i.e., username and password.
- 3. The logon process called the Local Security Authority (LSA) runs the logon authentication package.
- 4. The username and password are verified by the authentication package against the account information contained in the Security Accounts Manager (SAM).
- 5. If the logon information is found to be incorrect, the logon attempt is rejected, and the Logon Message dialog box appears, displaying a logon failure warning message.
- 6. If the logon information is valid, the authentication package creates a logon session and passes the necessary account information to the LSA for the Security Access Token (SAT) to be created.
- 7. The Win32 subsystem is called by the logon process to create a user process to which the Security Access Token is attached. The Win32 subsystem starts the Windows NT desktop.
Local Security Authority (LSA)
The Local Security Authority plays a key role in the Windows NT security system and provides the software interface between the user and kernel modes of Windows NT. Its main functions include:
- • Calling the appropriate user authentication package
- • Generating the Security Access Token
- • Logging audit messages generated by the Security Reference Monitor
- • Controlling the Audit policy
Security Access Token (SAT)
When a Windows NT logon occurs, the operating system generates a Security Access Token (SAT) containing the Security ID (SID) of the user who is logging on, the Security ID of any groups to which the user belongs, plus any user rights assigned to the user. The Security ID is discussed further in Chapter 5.
The SAT is only generated upon logon, so any changes made to either the user’s rights or to the groups to which the user belongs will only take effect when the user next logs on. In other words, if a user is currently logged on and added to the Administrators group, this group membership will only take effect when the user logs off and back on again. By comparing the Security IDs contained in the SAT to the permissions assigned to the object, Windows NT can verify that the user has sufficient permissions to access an object. Each process that runs on behalf of a user receives a copy of the SAT, which the process will use to access objects.
Security Reference Monitor
The Security Reference Monitor verifies whether the requested access to an object is allowed and whether the requesting process has permission to perform the required operation on the object. The Security Reference Monitor is also responsible for generating audit messages.
Access Control List (ACL)
The access control list (ACL) contains access control entries (ACEs). The ACEs contain access masks, which are used to identify which users or groups have been granted or denied access to an object. When access to an object—for instance, a file, printer, or folder—is requested, the security system searches the ACL to see if the requested access is allowed. The ACEs are ordered in the ACL so that the no-access ACEs are listed first. If the access to the object has been blocked, this ACE will be reached before the grant-access ACEs. Therefore, if a user requests access to a file with an ACE that allows access, but the user is also a member of a group that is denied access, the user will be denied access.
The following steps show the method used to either allow or deny access to an object.
- 1. When access to an object is requested, a desired access mask is created that contains the process’s access request.
- 2. The process’s SAT is compared to the first ACE in the ACL. If a match is found between the Security IDs contained in the SAT and those contained in the ACE, further processing of the access request is done. If no match is found in this ACE, the next ACE is checked in the same way. If no match is found in any ACE contained in the object’s ACL, access to the object is denied.
- 3. If access is denied, the desired access mask is checked to see whether the request is to change the object’s permissions. If it is, and the process requesting the access is either the owner of the object or an administrator, the access will be allowed. If not, access to the object will be denied and no further ACEs will be checked.
- 4. If the access is allowed, the ACL entries are checked until an ACE is found with the exact match to the desired access mask. If the match is found, the access is allowed; if not, the access is denied.
|
